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[57] ABSTRACT 

A method for dynamically sharing an application in a 
conference system while maintaining state regardless of 
whether the application is under execution in all conference 
devices. The conference system includes a plurality of 
conference devices with at least one conference device 
executing an application program. The method for dynami- 
cally sharing the application program among the plurality of 
conference devices in the conference system while main- 
taining state, includes the steps of: communicating a request 
to share the application program from a requesting confer- 
ence device which is executing the application to all enrolled 
conference devices; storing an executed state of the appli- 
cation program to be shared in the requesting conference 
device; . starting the application program to be shared by 
enrolled conference devices in which an application pro- 
gram corresponding to the application program to be shared 
is not started; communicating the executed slate stored in the 
requesting conference device to all enrolled conference 
devices; and processing by all enrolled conference devices 
of the application program to be shared in a shared executed 
state equal to the executed state communicated. 

5 Claims, 14 Drawing Sheets 
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SYSTEM AND METHOD FOR 
DYNAMICALLY SHARING AN 
APPLICATION PROGRAM AMONG A 
PLURALITY OF CONFERENCE DEVICES 

WHILE MAINTAINING STATE 5 

RELATED APPLICATIONS 

This application is a continuation of U.S. patent applica- 
tion Ser. No. 08/371,915, filed Jan. 12, 1995, now aban- 
doned. 10 

FIELD OF THE INVENTION 

The present invention relates to a conference system 
control method, a conference device, and a conference is 
system, and, more particularly, to a conference system 
control method, a conference device, and a conference 
system for opening a conference by using a plurality of 
conference devices connected by a network or communica- 
tion line such as a LAN, ISDN, or telephone line. 2 0 

BACKGROUND OF THE INVENTION 

In a conference system, each of a plurality of users 
connects each terminal to a line or network to open a 
conference while transferring data between terminals. In this 25 
type of system, conference systems for realizing an appli- 
cation program (hereafter referred to as an application) 
which can be shared by all users are roughly divided into 
"centralized" and "decentralized." 

The centralized system allows data to be input to an 30 
application from a plurality of user terminals and transmits 
output data to all user terminal. Rapport uses a centralized 
system (S. R. Ahuja, J. R. Ensor, and D. N. Horn, "The 
Rapport Multimedia Conferencing System," Proc. COIS 88, 
pp. 1-8, 1988). 35 

However, the centralized system is not preferable because 
much data is output from the application, increasing the load 
on hardware. Moreover, the centralized system is restricted 
in that the system must be applied to a server-client window 4Q 
system in which display processing and control are inde- 
pendently performed like the X-WINDOW SYSTEM which 
operates on UNIX. 

The decentralized system ensures the same state by 
executing the same application in each user terminal and 45 
cooperatively operating each application. The system is used 
for ASSOCIA (Yoshiyuki Nakayama et al., "A Computer- 
Supported Multiparticipant Realtime Teledialogue System," 
Thesis, Journal of the Information Processing Society of 
Japan, Vol. 32, No. 9, pp. 1190-1199, 1991) and MMConf 50 
(T. Crowley et al., "MMConf: An Infrastructure for Building 
Shared Multimedia Applications," Proc. CSCW 90, pp. 
32^-342, 1990). 

ASSOCIA keeps a plurality of instances (entities) of an 
application in the same state by ensuring at the system side 55 
that all data values input to all applications from a plurality 
of users coincide with each other in a time series. Therefore, 
it is possible to share the "instances" of all applications and 
keep them in the same state when start and execution are 
simultaneously performed in a plurality of user terminal, go 

With ASSOCIA, however, when a user by whom an 
application currently executed is not shared is going to share 
the application, the state of an application of a user who 
already shares the application may not coincide with the 
state of an application of a user who is going to share the 65 
application in the middle. That is, the application currently 
executed has already-read execution files and states such as 
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attribute values of the present application (e.g. cursor 
location, expansion or contraction, and fonts). Therefore, 
even if the same applications are started by other user 
terminals at the initial state and the same input is given to 
applications after they are shared, it is impossible to realize 
a shared application which coincides with any other appli- 
cation because each state when the application is shared 
differs. Therefore, to keep a currently-executed application 
in a consistent state when the application is shared, a 
low-level consistency of giving the same input is insuffi- 
cient. 

Also, in the case of MMConf, it is possible to keep a 
plurality of manifestations of applications simultaneously 
started in the same state but it is impossible to keep a shared 
application consistent because processing for sharing an 
application is not assumed. 

As another example of the above-mentioned, the official 
gazette of Japanese Patent Laid-Open No. Hei 3-192845 
discloses a method for controlling an interaction system 
serving as a conference system, which realizes a dialogue by 
the fact that a plurality of users accesses a network of 
terminals. This method realizes a dialogue equivalent to a 
conference by processing participation in the dialogue and 
the exit of a user who can attend a conference (enrollee) 
from the dialogue by each terminal so that participation and 
exiting can be done easily. 

However, the above interaction system control method 
only processes the participation in and exit from a dialogue 
equivalent to a conference. Therefore, it is impossible to 
keep a shared application consistent at the start of a confer- 
ence and during the conference because processing for 
sharing an application is not assumed. 

Moreover, the official gazette of Japanese Patent Laid- 
Open No. Hei 4-186456 discloses a common information 
processing system serving as a conference system making it 
possible for a plurality of users to perform a dialog and 
common information processing by connecting terminal to a 
network or line. This system allows each user to process 
electronic information in common with other terminals by 
performing a dialogue while referencing the same output 
result and so on. 

However, the common information processing system 
also has a restriction in that the system must be applied to a 
server-client window system in which display processing 
and control are independently performed like the 
X-WINDOW SYSTEM which operates on UNIX. 

Thus, there is a need for a more cost-effective conference 
system and method which allows dynamic sharing of appli- 
cations regardless of whether a user is currently executing 
the application. The present invention addresses such a need. 

SUMMARY OF THE INVENTION 

It is therefore an object of the present invention to provide 
a conference system whereby all user terminals executing a 
common application are maintained in a same state. 

It is yet another object of the present invention to bring 
user terminals joining a conference already in progress to a 
same state as other user terminals in the conference. 

According to the invention, a plurality of individual user 
terminals are joined together by a network. In operation, a 
requesting user terminal runing an application program 
requests a conference. While the application program may 
be of any type, for the purposes of illustration, a blackboard 
program is run whereby conferees attending the conference 
can write on the blackboard and erase the blackboard just as 
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a conferee might do when physically attending a conference 
in a conventional conference room. The requesting user 
terminal issues a request to share the application program 
with all conferee user terminals causing all conferee user 
terminals to load the application program. The requesting 
user terminal then transmits the current state of the appli- 
cation program to the conferee user terminals such that all 
user terminals are brought to the same state and the confer- 
ence can proceed with all conferees seeing the same things 
on their individual terminals. 

A. callback protocol memory is also provided for storing 
a processing program and identifiers corresponding to event 
information whereby when a state of the application is 
changed, such as by, for example, a conferee writing a 
message on the blackboard, the new state of the application 
is transmitted to all user terminals participating in the 
conference such that all such terminals maintain a same 
state. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a schematic block diagram showing the confer- 
ence system of the first embodiment; 

FIG. 2 is a schematic block diagram showing a terminal 
of the first embodiment; 

FIG. 3 is a block diagram showing the rough internal 
constitution of the computer of a terminal of the first 
embodiment; 

FIG, 4 is a corresponding diagram showing types of 
conference events, names, and parameters; 

FIG. 5 is a flowchart showing the flow of a start for 
dynamically incorporating a common application; 

FIG. 6 is a flowchart showing the flow of processing in a 
requesting terminal when a plurality of users shares a 
common application; 

FIG. 7 is a conceptual view showing the flow of process- 
ing in a requesting terminal when a plurality of users shares 
a common application; 

FIG. 8 is a flowchart showing the flow of processing in a 
requested terminal when a plurality of users shares a com- 
mon application; 

FIG. 9 is a conceptual view showing the flow of process- 
ing in a requested terminal when a plurality of users shares 
a common application; 

FIG. 10 is a schematic block diagram showing the con- 
ference system of the second embodiment; 

FIG. 11 is a conceptual view showing the flow of pro- 
cessing in an integrated controller when a plurality of users 
shares a common application in the second embodiment; 

FIG. 12 is a conceptual view showing the flow of pro- 
cessing in a request-side terminal unit when a plurality of 
users shares a common application in the second embodi- 
ment; 

FIG. 13 is a conceptual view showing the flow of pro- 
cessing in a requested terminal when a plurality of users 
shares a common application in the second embodiment; 

FIG. 14 is a schematic block diagram showing a confer- 
ence system for separately sending or receiving voice and 
animation information; and 

FIG. 15 is a schematic block diagram showing a different 
connection configuration among a plurality of terminals in a 
conference system. 

Description of Symbols 

10 . . . Conference system 
12 . . . Network 
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16, to 16^ . . . Terminal units 
18 a to XH K . . . Users 

DETAILED DESCRIPTION OF THE 
5 PREFERRED EMBODIMENT 

Embodiments of the present invention are described 
below by referencing the accompanying drawings. 

As shown in FIG. 1, a conference system 10 which is the 

J0 first embodiment comprises an annular network 12 for 
sending/receiving a digital signal and K (a natural number) 
terminals 16 1 to 16 K connected to the network 12. In the 
conference system 10, transfer data is transmitted through 
the network 12. Each terminal 16 1 to 16^ is operated by 

J5 users 18 a to 18^. The network 12 is not restricted to the 
above networks (Ethernet and Token Ring Network). It is 
possible to use a public telephone network, a network such 
as ISDN, or a combination of them as the network 12. 
Moreover, each terminal 16 1 to 16^ stores a conference 

2Q room system 11 as an execution program for progressing a 
conference through terminals among a plurality of users as 
described later. 

As shown in FIG, 2, the terminal 16,- (i:l = i=K) com- 
prises a personal computer (hereafter referred to as a PC) 22,- 

25 serving as a controller, a display 24,- serving as a display, and 
keyboard 26,- serving as an input unit. In addition to the 
above constitution, it is possible to connect a liquid crystal 
display or projector serving as a display, a mouse serving as 
a coordinate input unit, a camera serving as an image input 

30 unit, a microphone serving as a voice input unit, and a pair 
of speakers serving as voice output units. The microphone 
and the two speakers can be replaced with a head set such 
as a telephone set or transceiver. Moreover, it is possible to 
set the two speakers so as to produce a stereophonic effect 

35 or it is possible to use three or more speakers for multichan- 
nel reproduction or use one speaker for monaural reproduc- 
tion. Input processing can be made on a CRT without using 
a keyboard by connecting a mouse and voices can be input 
or output by connecting a microphone and a speaker. In 

40 addition to the above constitution, it is possible to connect 
a digitizer serving as a coordinate input unit, a printer 
serving as an output unit, and a scanner serving as an input 
unit. 

A PC 22,. comprises a CPU 28,, ROM 30,., RAM 32,., 

45 memory 34,-, and an input/output port I/O 36, connected by 
a bus 38, so that data and commands can be transferred 
between them. Memory 34, can use external memory such 
as a floppy disk drive, hard disk drive, or optoelectronic 
memory. The input/output port I/O 36,. is connected to the 

50 network 12 through a communication interface I/F 37,. and 
also connected to the display 24, and keyboard 26,., 

In FIG. 3, the outline of the internal constitution of the PC 
22,- for realizing the conference room system 11 in the 
terminal 16,- is shown in the form of a block diagram for each 

55 function. The PC 22,- has a communication control section 
40,. for communicating data or the like with another PC,- 
(j:l=j = K, i*j), a conference control section 42,. (described 
later) for controlling conference operations such as opening 
and closing of a conference (hereafter referred to as a 

60 conference room) opened among a plurality of terminal and 
an enrollee's entering and exit the room, a common appli- 
cation section 50, comprising one or more programs which 
are shared by enrol lees in the conference room and concur- 
rently used (e.g., a program or the like of a common 

65 blackboard on which a character or a diagram can be written 
or on which a character or diagram can be erased), and a 
common application management section 44,.. The common 
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application management section 44, includes a callback 
routine section 48,- comprising a processing program 
(hereafter referred to as a callback routine) to the common 
application section 50, for various instance processing 
(hereafter referred to as conference events; described later) 5 
in the case of the call of a common application service 
section 46„ and the common application section 50,. or 
operations of a conference. The common application service 
section 46, stores a processing routine included in a common 
application (e.g., a program for storing a state of a common 3Q 
application), which is called by an individual common 
application or by the common application service section 46 ; 
(i*j) of another terminal. 

The communication control section 40,- is connected to the 
network 12 in order to exchange data with a plurality of 35 
terminal used for one conference through a wide- are a net- 
work such as a LAN or ISDN and also connected to the 
conference control section 42, and the common application 
section 50,-. The communication control section may per- 
form one-to-one data transfer to and from another terminal 2 q 
separately from an opened conference. The conference con- 
trol section 42 ( . is connected to the common application 
section 50,-, common application management section 44,, 
and keyboard 26,.. The common application section 50,- is 
connected to the common application management section 25 
44,. 

The conference control section 42,- is a control section for 
processing a request for generation or deletion of a confer- 
ence room, communicating with the conference control 
section 42, of another terminal to process the acceptance of 30 
the request, and performing processing so as to synchro- 
nously keep the same contents relating to new enrollees in 
a conference and to the fact that a user having an application 
operating sends a conference event such as replacement or 
the like to the common application section 50,. For example, 35 
the section 42; manages a conference member as a enrollee 
to a conference and the common-application use right and 
has a function for notifying the common application of a 
change in the number of conference enrollees, of moving the 
use right to a conference enrollee as a conference event. 40 

Thus, for the conference system 11 of this embodiment, 
the conference control section 42,- for operating a conference 
and the common application section 50 ( - which is a confer- 
ence event section simultaneously used by enrollees in a 
conference and stores common applications are indepen- 45 
dently constituted. 

As shown in FIG. 4, the conference event CE shows 
details of conference state change. The conference event CE 
comprises an event name and a parameter. Corresponding to 
the conference event CE, a callback routine for processing 50 
the conference event CE concerned is previously registered 
in the callback routine section 48,-. In FIG. 4 t event names 
TERMINATE, NEW, OPEN, CLOSE, and DELETE are 
shown as the conference event CE for basic conference 
operations such as termination of conference processing, 55 
new conference, opening of conference, closing of 
conference, and deletion of conference; event names 
BEG INS HARE and ENDSHARE arc shown as the confer- 
ence event CE for sharing a requested common application 
such as beginning of assignment and ending of assignment 60 
for sharing; event names ENROLLED and UNENROLLED 
are shown as the conference event CE for changing enrollees 
in a conference room such as addition and deletion of 
enrollees; event names ENTER-START, ENTER- 
COMPLETE, LEAVE-START, and LEAVE-COMPLETE 65 
are shown as the conference event CE for newly participat- 
ing and exiting a conference room such as new participation 
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and exiting; and event names FLOOR-REGISTERED, 
FLOOR-UNREGISTERED, FLOOR-ENQUEUED, 
FLOOR-RELEASED, FLOOR-OBTAINED, AND 
FLOOR-CANCELED are shown as the conference event 
relating to the conference room control right such as entry, 
deletion, assignment, release, acquisition, and cancellation 
of the control right. 

Parameters serving as arguments of event names as the 
conference events include toolNumber, toolID, conflD, 
userlD, and floorlD. The parameter toolNumer corresponds 
to an identification number corresponding to a type of 
common application, the parameter toolID corresponds to an 
identification number when using a plurality of common 
applications for one conference under different states, the 
parameter conflD shows a conference room number (e.g., 
serial number), the parameter userlD corresponds to a user's 
identification number, and the parameter floorlD corre- 
sponds to an identification number corresponding to a type 
of control right. 

As shown in FIG. 3, the conference control section 42 ( - 
comprises a conference control request processing section 
52,-, a conference event processing section 54„ a common 
application registration section 56/, a conference event dis- 
tribution section 58,-, a conference event reception section 
60,, a common application table 62/, a callback routine table 
64,-, and a conference table 66,-. 

The conference control request processing section 52,- 
processes a request for conference state change from the 
terminal of its own or another terminal. The conference 
event processing section 54,. generates or delivers a confer- 
ence event corresponding to a conference state change. The 
common application registration section 56 ( . dynamically 
registers a common application at start or the like. The 
conference event distribution section 58,- distributes and 
outputs a conference event for a conference state change 
request to enrollees who can attend the conference. The 
conference event reception section 60, receives a conference 
event for a conference state change request from another 
terminal. 

The common application table 62,- is provided with serial 
numbers for common applications and stores serial numbers, 
common application names, the address of the module 
concerned where one common application is loaded in RAM 
(memory) as a module, and the address of the common 
application initialization routine. r Hie callback routine table 
64,- stores common application serial numbers in the com- 
mon application table 62,-, event names, and call back 
routine address. The conference table 66,. stores the number 
for a conference room which is currently opened and in 
which the user 18,- can participate, the conference room 
name, and the list of users who can use the conference room. 
Memory in which common applications are loaded is not 
restricted to RAM. It is possible to separately connect 
memory so that data is transferred to and from a terminal or 
add EMS memory or a cache memory. In this case, it is also 
possible to form main memory by adding EMS memory or 
cache memory to the terminal so that data can be loaded. 
This constitution is preferable because the device constitu- 
tion is simplified. 

A common application name (e.g., name of a dynamic 
link library to be loaded) used by a user in the conference 
room system 11 is stored beforehand in the common appli- 
cation management section 44,- as an application file APR 

The following is a description of the functions of this 
embodiment. For each terminal described below, a confer- 
ence room to be opened (used) when starting a conference 
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program references the conference table 66,. That is, a user The above processing is repeated for all common appli- 

who can attend a plurality of conference rooms is repeatedly cation names stored in the application file APR 

entered in the conference table 66,, Therefore, for example, Therefore, the conference control section 42, defines 

one or more conference rooms are selected by displaying the confereDce state change details as conference events (FIG. 

conference room list in the conference table 66,-or a plurality 5 4) m6 & deflned confcrencc cvents t0 the common 

of conference rooms is selected by default at the start of the applicalion 44 it ^ ible for a lura|it 

program. One field is registered in the conference table 66 f of confereQce evems of , common application t( f keep \ 

when a conference device is held. For example, when the consislent state mdependent of the conference state change, 

user 18,. opens a conference room an identification number ^ co nd to window events in a window system, 

■s given to the conference room and a conference room name 10 Ead) mjaaOB a Hcation re ^ sters ils own caUback routine 

corresponding to the identification number and a list of users k ^ conference contro , xt&)a 42 for , conference 6vent 

who can attend the conference room are stored. It is pref- ^ b eacn common a lication to k conference 

erable to obtain consent from persons who can attend the ev6n , consiste for each lerminal in lhe initia , ization 

conference room before stonng a hst of them. Though a routine of Mch common , ication wheQ conference 

plurality of conference rooms can be reg^tered in the 1S states ch the conference secUon 42 . ca ns the 

conference table 66,, the use of a single conference room use caUback rou , i(je retfstered for the confere nce event, 

is described below to simplify the description. Executuig a j, ^ , Q dynamicallv incorpora ,e common 

p ura ity of conference rooms on a terminal is to process a a lications> which m for a confer necessa ry al the 

plurality of conference rooms by means of individual tune- ^ of a conference am without chan p , he ^ tates of 

sharing one by one. Therefore, this processing corresponds 20 ^ conference 

to the processing of each conference room by means of «.,«... ... 

individual time-sharing interrupts or so^alled window pro- A method for shanng a common application currently 

cessing displaying a plurality of conference rooms on a exe ^ ted m the terminal ° f a use r bv a t U inference enroUees 

screen and selectively using a specific conference room. m ***** state independent of a conference room currently 

First, a method for obtaining only the common applica- 2S "P 6 "^ ' s d^nbed below by referencing FIGS. 6 to 9. To 

r c ■• c j simplify the description, it is assumed that a common editor 

tion necessary for operating the conference concerned or a „ \. *_ . F ... 0 

r . u * j 1 u u e S which is the common editor S serving as a common 

common application to be executed only by each user from . , „ t , , r 

, 1W r 1*- • 1 j j • « application locally executed only at the terminal 16. of a 

a plurality of common applications mcluded in the common *• c * « « * £ j 

r »• t - en a u *u <• 4i user Am a conference room opened by three users A, B, and 

application section 50. and how the conference control „ . . JU *u.u i* ■ f .. , , 

ri_ » r j . * jr Cis shared by the three users. It is also possible to assume 

section of each user transfers data to and from a common 30 . y V ~r ^ , L 

t - j . . , 4 t . «n. ^- that a common application executed only by one user 

application are described below together with Starting t . , e • L _i u .1 

» • t-t/^ e outside the conference room is shared by three users, 

routine in FIG. 5. J 

When a power switch (not shown) of a PC 16,. of a According to input through a keyboard 26 of the user A, 

terminal is turned on and the terminal 16,. is ready for a ^ u f. for Aam * the conference even < ° f the common 

operation and the conference room system 11 for performing 35 edlto . r S , f output to a conference control section 42* of the 

operations such as opening of a conference and participation tetmwal of the user , A ( ste P 202 > ^ re ^ es, . ,s l °P ut 

in the conference is started through a keyboard, the common j°. a ?° nt " e ° c e ™ lr 2 l T «* ucsl P rocessln 8 sec "° n 52 * 

application registration section 56/ of the conference control V sl S Da P a > • )> 

section 66,- reads one common application name from the ^ conference control request processing section S2 A of 
application file APF storing common application names 40 the user A generates a conference event CE with the event 
(step 102). Then, it is determined whether all common name BEGINSIIARE necessary for processing and outputs 
application names stored in the application file APF are read the conference event (event name: BEGINSHARE) to a 
by determining the end of the application file APF (step conference event distribution section 58 A (step 204, signal 
104). In the case of a negative determination, a module P ath G2 )- ^ conference event distribution section 5S A 
stored in memory 34/ corresponding to a common applica- 45 references a conference table 66 A (signal path G3 in FIG. 7) 
tion with the read name is loaded in RAM (memory) by the t0 determine that users A, B, and C are enrollees at a 
common application registeration section 56,. (step 106). The conference room and distributes the conference event to 
common application' registration section 56, gives a serial these tnree ( ste P 206 )> ^ conference event is also 
number to the common application with the read name and distributed to the user A who requested sharing of the 
enters the serial number, the common application name, the 50 conference event and the transfer data designating users B 
address of the module loaded in RAM (memory), and the and c 15 0Ut P ut t0 terminal 16^ and 16 c of users B and C 
address of an initialization routine in the common applica- through a communication control section 40 A and the net- 
Lion table 62,- (step 108). The initialization routine is located work 12 ( Sl &* al P alh G4 )- 

at a predetermined location (e.g., first opening function) of Conference event reception sections 60 A , 60 5 , and 60 c of 

the loaded module, which sets a default and includes the 55 users A, B, and C receive a conference event. Details of 

address of a callback routine corresponding to a conference processing for users B and C are described later. The 

event included in a common application. Then, the common conference event received by the conference event reception 

application registration section 56,. calls the initialization section 6Q A is output to a conference event processing 

routine of the common application with the read name (step section 54^ (step 208, signal path G5). 

110) and obtains the address of a callback routine corre- 60 The conference event processing section 54^ reads a 

sponding to a conference event from the called initialization conference number and common application number from 

routine (step 112). Then, the common application registra- the parameter of the input conference event(depicted in FIG. 

tion section 56 ( - establishes a correspondence between the 4), references a callback routine table 64 A (signal path G6) 

address of the callback routine thus obtained, a common to obtain the address of a callback routine corresponding to 

application number and an event name and enters the 65 the conference event of the common application, and 

common application number, event name, and callback requests starting of the callback routine (signal path G7). A 

routine address in the callback routine table 64 t - (step 114). common application management section 44 A calls the 
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requested callback routine and starts it (step 210). The Synthetically, a request for sharing the conference event 

conference event processing section 54 A waits for the next of the common editor is issued to the conference control 

processing until the processing of the callback routine section of the user A from the user A, the conference control 

terminates. This processing is executed in the callback section of the user A communicates with conference control 

routine of the common editor independently of the confer- 5 sections of users B and C, and a callback routing for sharing 

ence control section. me conference event of the common editor S is called by 

tl„ „ 0 iik«„u n f tu a ~~ n i- . _ terminals of users A, B, and C. The callback routine of the 

ine callback routine oi toe common application orders .. «- A - • i . 

e * .u A* * • * common editor of the user A communicates with the call- 

tnc common editor S of the user A to terminate processing U1 c ... c n j ^ 

/ - i iL r^o\ j i j-. o • . back routine of the common editor of users B and C. The 

(signal path Go) and the common editor S terminates * • i *. a * * * 

v & s ' , . , , / , in common editor of the term inal of the user A first terminates 

processing currently being executed (step 212). 30 . 

r ° j a \ r / execution or all processing before sharing to wait for the 

When receiving termination of processing, the common stale to become steady and thereafter starts the common 

application section of the user A stores the current state of editor with terminals of B wd c MiGT it ^ confirmed 

the common editor S (e.g., read data file, portion currently lhat the common editor is slarted by editors of users B and 

edited, or cursor location) and outputs the stored state to r the current state of the common editor S is sent to users 

users B and C (step 214, signal path G9). B and c Wheo the above pr0C essing terminates, users A, B, 

After state output to users B and C terminates, the and C terminate callback routine processing. When callback 

common application section 50 A outputs a termination sig- routine processing terminates and control returns to the 

nal to the conference event processing section 54 A to ter- conference control section, common editors S in the same 

minate processing of conference event which is conference state are working in terminals of three users. Thereafter, it is 

control in the conference event processing section 54 A (step possible to input data to the common editor. 

216, signal path G10). Thus, it is possible to share a common application under 

Processing by terminals 16 s and 16 c of users B and C is execution by clearly separating conference control section 

described below. Because almost the same processing is processing from that of the common application, managing 

performed for users B and C, processing by the terminal 16 B 25 the conference event notification of sharing a common 

of the user B is described below for simplicity. application by the conference control section, providing the 

When a signal based on transfer data is input to the common application with functions for storing the current 

conference event reception section 60 B from the terminal of execution state and realizing a new state, and shifting to the 

another user (signal path G20, FIG. 9), the sharing routine same state by synchronizing common terminal applications, 

in FIG. 8 is executed and the conference event reception 30 The second embodiment is described below. In the first 

section 60^ receives a conference event. The conference embodiment, a case is described in which only the terminal 

event received by the conference event reception section 60^ of each user participating in a conference is connected by a 

is output to the conference event processing section 54 fl network or the like. However, the present invention is not 

(step 222, signal path G21). restricted to the above case. As shown in FIG. 10, it is also 

The conference event processing section 54^ reads a 35 possible to manage a conference by connecting one or more 
conference number and a common application number from centralized managing devices 17 to a network or the like, 
the parameter of the input conference event and references For the second embodiment, the same portion with that of 
the conference table 66 B (signal path G22a) and the callback the first embodiment is provided with the same symbol and 
routine table 64 B (signal path G22) to obtain the address of its detailed description is omitted. Therefore, only portions 
a callback routine corresponding to the conference event of 40 different from those of the first embodiment are described 
a conference room in which a common application is below. The conference system 10 of this embodiment, as 
included and requests starting the callback routine (signal shown in FIG. 10, comprises an integrated controller 17 
path G23). A common application managing section 44^ comprising a host computer such as a microcomputer con- 
calls the requested callback routine to start it (step 224). The nected to a network 12 and L (L is a natural number) 
conference event processing section 54 B waits for the next 45 terminal 16 x to 16^. 

processing until processing of the callback routine tcrmi- As shown in FIG. 11, the integrated controller 17 corn- 
nates, prises a communication control section 41 for communical- 

The callback routine of a common application designates ing data with a terminal and a conference control section 43 

starting the common editor S serving as a common appli- for controlling conference operations such as activation and 

cation corresponding to the common editor S of the user A 50 termination of a conference room opened among a plurality 

(signal path G24) and starts the common editor S at the of terminals and enrollees entering and exiting the confer- 

terminal B of the user B (step 226). In this case, it is ence. The communication control section 41 is connected to 

preferable for the common application to store all current the network 12 and also to the conference control section 43. 

states or accept a state sent from another unit as a new state The conference control section 43 comprises a conference 

to realize sharing during execution. 55 control request processing section 53, a conference event 

When receiving termination of a start, the common appli- distribution section 59, and a data storage section 51 for 
cation section of the user B waits until reception of transfer holding an executed state of a common application. The 
data to be shared sent from another user terminates (step conference control request processing section 52, generates 
228, signal path G25). When reception of transfer data a conference event corresponding to a change in the con- 
terminates, the common editor of the user B performs 60 fere nee state when a request for changing conference states 
processing so as to coincide with the state of the common is output from various terminals. The conference event 
editor S of the user A (step 230). After processing terminates, distribution section 58,. distributes and outputs a conference 
the common application section 50^ outputs a termination event for a conference state change request to enrollees in 
signal to the conference event processing section 54^ to the conference. 

terminate processing of the conference event which is con- 65 A terminal 16 A comprises a PC 22 A , a display 24 A and a 

ference control in the conference event processing section keyboard 26 A like that of the first embodiment. Because 

54 fl of the user B (step 232, signal path G26). other terminals have the same constitution, their description 
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is omitted. As shown in FIG. 12, the PC 22 A of the terminal cation file APF are read by determining the end of the 

16 A mainly comprises a communication control section 40 A application file APF (step 104). In the case of a negative 

for communicating data with another PC, (j:l=j=L« i *j) determination, a module stored in memory 34,- correspond- 

and the integrated controller 17, a conference control section ing to a common application with the read name is loaded in 

42„ (described later) for executing a conference room 5 ram (memory) by the common application registration 

opened at a terminal, a common application section 50 A section 56 ( (step 106). The common application registration 

comprising one or more programs shared by users and s6 ives a number , 0 the application 

concurrently used in a conference room, and a common wUh , he rMd Qame and eQters (he KtM numbc the CQm . 

apphcation management section 44 The communication m(m applicatioil namej tne address of the module loaded m 

con rol section 4 0 is connected o the network 12 and a M ^ (mem }> and the address of „ initializatioD rouline 

keyboard 26 A and also connected to the conference con rol in , he common ; pplication lable 62 (step 108 ). The initial- 

sectton 42 A and the common apphcatton section 50 A . lUe ^ton (omiae b located a , , prede ' termmed location ( 

communication control sectton may perform one-to-one fi[sl . func , ion) of ^ |oaded modu| which ^ 

data transfer to and from other terminals separately from an lne 0 f confcrcnc and a default and includes the address 

opened conference. The conference control section 42. is f ,,, , c 

K . , ... _ A , A 35 of a callback routine corresponding to a conference event 

connected to the common application section 50. and com- :„ „ ^ ™r««.*~, tu~~ ~ 

... rr . a* rw« included in a common application, inen, the common 

mon application management section 44.. The common i- * . # . * ... v t > 

f . . , A application registration section 56, calls the mitiahzation 

application section 50, is connected to the common apph- of me common , ication wjth , he read name (st 

cation management section 44 A . uo) ^ Qbtains ^ of a ^ 

fhe conference control section 42„ comprises a common 20 sponding t0 a conference event from the called initialization 

application registration section 56 A a conference event dis- routine (st U2) Theil) lhe common application registra- 

tnbution section 5& A , a conference event reception section lioD 56f establishes a correspondence between the 

60 A , a common application table 62 A , a callback routine address of the callback routine thus obtained and to a 

table 64 A , and a conference tabic 66 A . common application number and an event name and enters 

The conference event processing section 54,. delivers a 2 s the common application number, event name, and callback 

conference event corresponding to a conference stale routine address in the callback rouline table 64,- (step 114). 

change. The common application registration section 56,. ^ aboye ^ js ated for a „ common ,;_ 

dynamicaUy registers a common application at starting or ca , ioD names ^ fa (he a lication file ^ 

the like. The conference event reception section 60, receives . 

a conference event for a conference state change request sent 30 Th erefore » the conference control section 42, defines 

from the integrated controller. conference state change details as conference events (FIG. 

r . • c ... . 4 . u j u i 4) and reports defined conference events to the common 

The functions of this embodiment are described below. ' . r . ™ ... n * 

0 , , - ic.u- lj- * c application section 44,, Thereby, it is possible for a plurality 

For each terminal of this embodiment, a conference room Kr e e • i 

a t a\ u * _** f - or conference events of a common application to keep a 

opened (used) by starting a conference program is per- j j r*i_ c . 

e _ au * • p * c consistent state independent of the conference state change, 

tormed by referencing a conference event and the confer- 35 & 

ence table 66, from the integrated controller. That is, a user A procedure for sharing a common application under 

who can use a plurality of conference rooms is repeatedly execution is described below by referencing FIGS. 11 to 13. 

entered in the conference table 66... Therefore, one or more Hereafter, to simplify the description, it is assumed that a 

conference rooms are selected from the conference room list common editor S which is the common editor S serving as 

of the conference table 66, by the integrated controller or one 40 a common application locally executed only at the terminal 

or more conference rooms are selected by default, for 16 A of a user A in a conference room opened by three users 

example, at the start of the program. A field is registered in A > B > and C 15 shared b V lhe three 11 15 also P ossible 

the conference table 66, and the table 66, transmits the 10 assume that a common application executed only by one 

registered field to the integrated controller 17 when a user outside the conference room is shared by three users, 

conference is opened. Because it is possible to register a 45 According to input through a keyboard 26 A of the user A, 

plurality of conference rooms in the conference table 66,, a a request for sharing the conference event of the common 

case of registering one conference room is described below editor S is output to the integrated controller 17 (signal path 

for simplicity. G32 in FIG. 11 and the signal path 31 in FIG. 12). 

First, the start processing of this embodiment is described The conference control request processing section 53 of 
below. Because the start of this embodiment is almost the 50 lhe integrated controller 17 generates an conference event 
same as that of the first embodiment in FIG. 5, it is described CE with the event name BEGINSHARE necessary for 
by referencing FIG. 5 by giving the same number to the processing and outputs the conference event (event name: 
processing equivalent to that in FIG. 5. When a power BEGINSHARE) to a conference event distribution section 
switch (not shown) of a terminal PC 16, is turned on, the 59 (signal path G33, FIG. 11). The conference event distri- 
terminal 16, is ready for operation and the conference room 55 bution section 59 references a conference table 67 (signal 
system 11 for performing operations such as opening of a path G34 FIG. 11) to determine that users A, B. and C are 
conference and participation in the conference is started by enrollees at a conference room and distributes the confer- 
a designation through a keyboard, and data is sent to an ence event to these three users. The conference event is also 
integrated controller. The integrated controller references a distributed to the user A who requests sharing of the con- 
conference table 67 and sends a conference event showing 60 ference event and terminals 16^ and 16 c of users B and C 
the start to the started terminal. The common application through a communication control section 41 of the inte- 
registration section 56, of the conference control section 66, grated controller 17, network 12, and communication con- 
of the terminal 16, receiving the conference event showing trol sections 40 A , 40^, and 40 c (signal path G35, FIG. 11; 
the start reads a common application name from the appli- signal path 36, FIG. 12; signal path 37, FIG. 13). 
cation file APF storing common application names 65 Conference event reception sections 60^, 60 B , and 60 c of 
(corresponding to step 102, FIG. 5). Then, it is determined users A, B, and C receive a conference event. The confer- 
whether all common application names stored in the appli- ence event received by the conference event reception 
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sections is outputted to each conference event processing 
section (signal path 38, FIG. 12; signal path 39, FIG. 13). 
Each conference event processing section 54 reads a con- 
ference number and common application number from the 
parameter of the input conference event, references a con- 
ference table and a callback routine table (signal path 40, 
FIG. 12; signal path 41, FIG. 13) and obtains the address of 
a callback routine corresponding to the conference event of 
the common application to request starting the callback 
routine (signal path 42, FIG. 12; signal path 42a, FIG. 13). 
Each common application management section calls and 
starts the requested callback routine. Each conference event 
processing section waits for the next processing until the 
processing of the callback routine terminates. Subsequent 
processing is executed in the callback routine of a common 
editor independent of the conference control section. 

The callback routine of the common application of the 
user A requesting sharing orders the common editor S of the 
user A to terminate processing (signal path G43) and termi- 
nates the processing of the common editor S currently being 
executed. The common application section of the user A 
receives the termination of processing, stores the current 
state of the common editor S, and outputs the stored state to 
the integrated controller 17 (signal paths G44 and G44a). 
Thereafter, to terminate the processing of the conference 
event which is the conference control in the conference 
event processing section 54 A , the common application sec- 
tion 50 A outputs a termination signal to the conference event 
processing section 54 A (signal path G45). 

Then, processing by terminals 16 B and 16 c of users B and 
C for which sharing is requested is described below. Because 
almost the same processing is performed for users B and C, 
processing by the terminal 16^ of the user B is described 
below for simplicity. 

Base on the conference event sent from the integrated 
controller 17, the conference event processing section 54^ 
reads a conference number and a common application 
number from the parameter of the input conference event, 
references a conference table and the callback routine table 
64^ and obtains the address of a callback routine corre- 
sponding to the conference event of the conference room 
including a common application to request starting the 
callback routine (signal path G42a). The common applica- 
tion managing section 44^ calls and starts the requested 
callback routine. The conference event processing section 
54 a waits for the next processing until callback routine 
processing terminates. 

The callback routine of a common application orders 
starting the requested common editor S (signal path G46) 
and starts the common editor S at the terminal 16 B of the 
user B. In this case, it is preferable to set the common 
application so that it can store all current states and receive 
a state sent from an external unit as a new state to realize 
sharing during execution. 

By receiving the start termination, the common applica- 
tion section of the user B waits until the reception of transfer 
data from the integrated controller 17 terminates (signal path 
G47). The user B then processes the common editor S so that 
the state of the common editor B coincides with the state of 
the common editor S of the user A. After processing 
terminates, the common application section Si) B outputs a 
termination signal to the conference event processing sec- 
tion S4 B to terminate processing of the conference event 
which is conference control in the conference event pro- 
cessing section 54 B of the user B (signal path G48). 

Therefore, the conference control section of each user 
communicates with the integrated controller, the callback 
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routine for sharing the conference event of the common 
editor S by terminals of users A, B, and C, and it is possible 
to perform processing so that common editors in the same 
state arc operated in terminals of the three users. 

5 Thus, because this embodiment manages generation and 
reporting of a conference event sharing a common applica- 
tion by an integrated controller, it is possible to decrease 
additional processing of each terminal and share a common 
application under execution by using fewer execution pro- 

10 grams and less memory. 

The conference system 10 of the above embodiment also 
makes it possible to send or receive voice information 
including the voice of a user and music and animation 
information including the face of the user as transfer data. In 

15 this case, it is also possible to send or receive voice and 
animation information through transmission means 13 such 
as a separate line or separate network as shown in FIG. 14. 
Therefore, by sending or receiving voice information and 
animation information through a separate line or network, it 

20 is possible to decrease data capacity and manage a confer- 
ence in real time even using conference system having voice 
and animation information as data. 

In the above embodiment, a case of using the annular 

25 network 12 is described. However, as shown in FIG. 15, it 
is also possible to connect a plurality of terminal to one 
terminal 16^ (X=any one of 1 to N) or connect a plurality of 
terminals to an integrated controller 17. 
As processing for making other user attend an opened 

3 q conference, it is preferable to perform attendance request 
processing for asking whether the user attends the confer- 
ence with a terminal 16, for which attendance is requested. 
In this case, it is preferable to set a terminal 16 t of the 
attendance request side when requesting another user to 

35 attend the conference so that the terminal cancels the above 
attendance procedure when transfer data showing that other 
user 18y refuses attendance is returned or no response returns 
because the other user 18, does not operate the terminal 16 ; 
or is out (after a preset time of a timer lapses). 

40 Moreover, to proceed with the conference, the common 
application use right may come into contention. In the case 
of the above common blackboard, the common blackboard 
use right contends because a plurality of users simulta- 
neously request the common blackboard use right. In this 

45 case, it is necessary to make users wait their turn to obtain 
the use right by giving priority to the use right. Data showing 
use right permission and the tum are sent to the conference 
event reception section and the common application section 
of each user. Based on this data, the conference event 

50 processing section allows a user to use the common black- 
board. It is preferable to set up an application program for 
the common blackboard to enable a user to input data with 
an input unit such as a keyboard or mouse and to send data 
for making input by users other than the permitted user 

55 impossible to prevent erroneous input. 

As described above, the present invention has advantages 
that only a dynamically necessary application among a 
plurality of applications can be incorporated into a real-time 
conference system for multiple enrollees in which appiica- 

60 tions are executed by the conference device of each enrollee 
at the start of the conference system and these applications 
under execution can be started and shared by the terminal of 
another user in the same state. 
Having thus described our invention, what we claim as 

65 new and desire to secure by Letters Patent is: 

1. In a conference system including a plurality of confer- 
ence devices with at least one requesting conference device 
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executing an application program to be used in a conference, 
a method for dynamically sharing the application program 
among the plurality of conference devices while maintaining 
a same state of the application program at each of the 
plurality of conference devices, said method comprising the 5 
steps of: 

communicating a request to share the application program 
from said requesting conference device executing the 
application program to other ones of said conference 
devices enrolled in the conference; 10 

storing a current state of the application program in the 
requesting conference device; 

loading the application program by said other ones of said 
conference devices enrolled in the conference; 15 

communicating the current state from the requesting 
conference device to said other ones of said conference 
devices enrolled in said conference; and 

processing the application program by said other ones of 
said conference devices enrolled in said conference to 20 
acquire a state equal to the current state. 

2. The conference system as recited in claim 1 wherein the 
application program is a blackboard program for displaying 
a screen on said conference devices on which users can write 
messages. 25 

3. In a conference system including a plurality of confer- 
ence devices wherein a requesting conference device is 
executing an application program, said requesting confer- 
ence device adapted for dynamically sharing the application 
program among the plurality of conference devices while 30 
maintaining said plurality of conference devices in a same 
state, said requesting conference device comprising: 
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application program storage means for storing an appli- 
cation program used for a conference; 

callback protocol storage means, coupled to the applica- 
tion program storage means, for storing a processing 
program along with identifiers for sharing the applica- 
tion program; 

conference control means for maintaining all conference 
devices in a same state coupled to the callback protocol 
storage means, wherein one or more registered identi- 
fiers of the processing program corresponding to event 
information indicating a changed state of a conference 
are previously stored, said conference control means 
communicating the event information corresponding to 
the changed state to all said conference devices, said 
conference control means further for changing a con- 
ference execution state to be equal to the changed state 
corresponding to communicated event information and 
executing the processing program corresponding to the 
communicated event information by referencing the 
registered identifiers; and 

communication control means, coupled to the conference 
control means, for communicating transferred data 
including the event information. 

4. The conference device of claim 3, where the plurality 
of conference devices communicatively couple so that the 
event information can be input or output. 

5. The conference system as recited in claim 3 wherein the 
application program is a blackboard program for displaying 
a screen on said conference devices on which users can write 
messages. 
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